The OPC communication may fail in various ways, or the OPC client may get disconnected from the OPC server. Here are some examples of such situations:

• With OPC Classic, the OPC server may not be registered on the target machine – permanently, or even temporarily, when a new version is being installed.
• With OPC UA, the OPC server may not be running or registered with the discovery service on the target machine – permanently, or even temporarily, when a new version is being installed.
• The (DCOM, TCP, Web service or other) communication to the remote computer breaks due to unplugged network cable.
• The remote computer running the OPC server is shut down, or restarted, e.g. for security update.
• The configuration of the OPC server is changed, and the OPC information (item in OPC Classic, node and attribute in OPC UA) referred to by the OPC clients no longer exists. Later, the configuration could be changed again and the OPC item may reappear.
• The OPC server indicates a serious failure to the OPC client.
• The OPC Classic server asks its clients to disconnect, e.g. for internal reconfiguration.

QuickOPC handles all these situations, and many others, gracefully. Your application receives an error indication, and the component internally enters a “wait” period, which may be different for different types of problems. The same operation is not reattempted during the wait period; this approach is necessary to prevent system overload under error conditions. After the wait period elapses, QuickOPC will retry the operation, if still needed at that time.

All this logic happens completely behind the scenes, without need to write a single line of code in your application. QuickOPC maintains information about the state it has created inside the OPC server, and re-creates this state when the OPC server is disconnected and then reconnected. In OPC Classic, objects like OPC groups and OPC items are restored to their original state after a failure. In OPC UA, objects like OPC subscriptions and OPC monitored items are restored to their original state after a failure.

Even if you are using the subscriptions to OPC items (in OPC Classic) or to monitored items (in OPC UA) or events, QuickOPC creates illusion of their perseverance. The subscriptions outlive any failures; you do not have to (and indeed, you should not) unsubscribe and then subscribe again in case of error. After you receive event notification which indicates a problem, simply stay subscribed, and the values will start coming in again at some future point.

In QuickOPC-UA, you can call a static method EasyUAClient.RetryAll to force a retrial on all objects that are in a failure state. This method terminates the waiting delay, and causes all such objects to be retried on next opportunity.